1. Field of the Invention
The present invention relates generally to Virtual Machine (VM) technology and, more particularly, to methods and systems for optimization of VM guest code.
2. Background Art
With VM technology, a user can create and run multiple operating environments on a computer at the same time. Each operating environment, or Virtual Machine, requires its own operating system (OS) and can run applications independently. The VM software provides a layer between the hardware of the computing system and the software that runs on it.
Frequently, the problem arises of simultaneously running different operating systems on the same hardware system. For example, with one version of MICROSOFT WINDOWS running on the computing system, it can be necessary to start another instance or another version of WINDOWS or another operating system, on the same hardware system.
A typical Virtual Machine Monitor (VMM) enables a single physical machine or processor to act as if it were several physical machines. A VMM, typically jointly with a high-ranking OS (although there are VMMs that can be executed on bare hardware, without a high-ranking OS), can run a number of different operating systems simultaneously, such that each of the different operating systems has its own VM. In other words, a typical VMM can handle a number of VMs, each of which represents its own OS, and each of which can run its own application software and control or use its own hardware, including certain types of processors, I/O and data storage devices, and so on, as if they were running on a single processor. The high-ranking OS is typically referred to as a “host OS” (HOS), or a “Primary OS.” The multiple operating systems that are running as VMs are typically referred to as “guest operating systems” (“guest OSs”) running “guest code.”
A conventional approach for implementing VMs includes a VMM approach developed by IBM and implemented on mainframes, which support virtualization. Another approach includes implementing VMM on modern processors, which do not support the hardware virtualization, such as full step-by-step or page-by-page interpretation of the original code, or full binary translation of the original code, or combining binary translation of some portions of the original code and direct execution of other portions of the original code.
One of the common problems in Virtual Machine technology is the overhead that results from processing of privileged but unsafe instructions, also known as processing of “code under control.” In particular, in the context of many Virtual Machine implementations, such as, for example, described in U.S. patent application Ser. No. 11/139,787, entitled METHODS AND SYSTEMS FOR SAFE EXECUTION OF GUEST CODE IN VIRTUAL MACHINE CONTEXT, filed on May 31, 2005, which is incorporated herein by reference in its entirety, the high cost of the exceptions needed to handle the privileged but unsafe instructions is of particular concern. In other words, triggering, or raising, the exceptions is one of the major sources of overhead.
In reality, the number of instructions that are actually privileged but unsafe is relatively low. A significant percentage of overhead relates to handling of jumps within the code, where it is necessary to ensure that the execution of the code does not start executing in an area of memory, or in a page in memory, where it is not supposed to be. Thus, exceptions are normally needed to handle such transfers of control, where the exception is used to analyze the destination address to which control is transferred, and also to process any related activities, such as analysis of the code at the destination address, etc. The control transfers can be handled by placing an INT3 interrupt, instead of the JMP instruction (or some similar instruction), to switch the context to the Virtual Machine Monitor (VMM), where the JMP instruction is then handled or emulated. The JMP instruction itself normally has a ring 3 level of privilege (using the INTEL architecture terminology), if it is part of the guest code. The JMP instruction is therefore replaced by an INT3 interrupt, which changes the context from the guest code/VM context (ring 3) to the VMM context, which is at ring 0. Upon the raising of the exception with INT3, the VMM loads its own register flags (which is inherently part of the context switching), and then proceeds to analyze the jump instruction to determine just what exactly needs to be done to handle this situation.
The handling of the JMP instruction can involve the decoding of instruction, emulation of the instruction and then subsequently switching the context back to the VM and guest code. This entire process, in the Pentium IV architecture takes approximately 4,000 clock cycles.
The JMP instruction itself, in the native mode, can take on the order of 10-30 clock cycles to execute (depending on the processor, processor model, and the type of the JMP instruction). In other words, processing JMP instructions by treating them as privileged but unsafe instructions is approximately two orders of magnitude more costly compared to executing them in a native mode using direct execution. Xen provides a common HVM (hardware virtual machine) abstraction to hide the minor differences between the Intel and AMD technologies and their implementations. HVM offers two features: First, for unmodified guest operating systems, it avoids the need to trap and emulate privileged instructions in the operating system, by enabling guest OSs to run at their native privilege levels, while providing a hardware vector (called “VM EXIT”) into the Virtual Machine Monitor whenever the guest OS executes a privileged instruction that can unsafely modify the machine state. The hardware takes more than 1000-4000 CPU clock cycles to save the state of the currently executing guest OS and to transition into the VMM or Hypervisor. This sometimes lead to loss of performance comparing to execution code in the VM.
Accordingly, there is a need in the art for efficient execution of transfers of control in the guest code in a VM context.